home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
090
/
rpc161a1.arc
/
RPCMERGE.DOC
< prev
next >
Wrap
Text File
|
1988-04-13
|
11KB
|
297 lines
*****************************************************************************
************************ RBBS-PC Protocol Controller ************************
************************ By John Morris ************************
*****************************************************************************
To start... This had to be the most scary mod I've ever written. The
concept was simple, make a very flexible and expandable file transfer
system for my RBBS. But actually cutting out whole chunks of RBBS, and
putting untested code in was scary.. but, in the end it worked after
the second compile.
I completely re-did the whole RBBS transfer protocol interface. This
was needed so SysOps didn't have to bled in a new merge, and then compile
the program just to add a new protocol (or take one out). IE: I had to
make the program 'assume nothing' (well... almost).. I thought it was
going to be a huge task.. but I think in the end the code is actually
smaller than normal.
NOTE: (4/13 16-1A version)
RPC Merge for RBBS-PC 16-1A will work BLED and compile into RBBS-PC
without having to make room for the new code. All that is required is
that you use the batch file that I supply to compile RBBS-PC. The docs
say to compile RBBS-PC.BAS with the /E option (for error checking), BUT
RBBS-PC.BAS does NOT have an ON ERROR statement, nor any RESUME linenumber
statements, so the /E option is NOT needed!
How it works:
The whole new xfer system revolves around one file: RBBSXFRx.DEF
where 'x' is the node number. Single node systems would have a file
called RBBSXFR1.DEF
Here is what my RBBSXFR1.DEF file looks like:
Z,Zmodem,c:\ext\RZ,c:\ext\SZ,E,DSZ,2
I,Imodem,c:\ext\RI,c:\ext\SI,E,QMX,1
B,Ymodem Batch,c:\ext\RB,c:\ext\SB,E,DSZ,8
W,Wxmodem,c:\ext\WXR,c:\ext\WXS,E,QMX,0
K,Kermit,c:\ext\KERMITR,c:\ext\KERMITS,E,QMX,5
G,YmodemG,c:\ext\RG,c:\ext\SG,E,DSZ,9
For sysops with TWO OR MORE nodes:
Here is what my RBBSXFR2.DEF (node 2) file looks like:
Z,Zmodem,c:\ext\RZ,c:\ext\SZ,D,DSZ,2
I,Imodem,c:\ext\RI,c:\ext\SI,D,QMX,1
B,Ymodem Batch,c:\ext\RB,c:\ext\SB,D,DSZ,8
W,Wxmodem,c:\ext\WXR,c:\ext\WXS,D,QMX,0
K,Kermit,c:\ext\KERMITR,c:\ext\KERMITS,E,QMX,5
G,YmodemG,c:\ext\RG,c:\ext\SG,D,DSZ,9
(NOTE: The order in which you place the protocols does NOT matter!)
In my case Node 1 has much less memory to work with, so all I Exit RBBS
for all my Xtra protocols. Node 2 I SHELL Directly to the external protocol
drivers.
Lets break one line of that down so you know what is going on.
Z,Zmodem,c:\ext\RZ,c:\ext\SZ,D,DSZ,2
Z - This is the character which selects this protocol
Zmodem - This is the name of this protocol
c:\ext\RZ - This is the download batch file name
c:\ext\SZ - This is the upload batch file name
D - This is the method to use to call this protocol
DSZ - This is the method used to check for success
2 - This is an option preferred when using this protocol
In other words, The protocol name is Zmodem, to pick Zmodem, you use the
character Z. The batch file used to run a Zmodem download is C:\EXT\SZ.BAT,
and the Zmodem upload file is C:\EXT\RZ.BAT. The method used to call
Zmodem is shell D)irect to the protocol driver. After the xfer, you check
for success using the DSZ method.. and the option you would like for Zmodem
is not to show the user the number of blocks, just the size of the file.
File Selection Character
------------------------
The file select character can be any character you like. (only one
character though, please). You could add a couple more protocols to my
list.. M for Megalink, or S for Sealink, etc.
File Transfer Protocol Name
---------------------------
You could name the file xfer protocol anything you wish. For instance,
you could rename Zmodem to Zmodem (DSZ) or Ymodem could be:
True Ymodem.. or Xmodem-1k..
Download & Upload Batch files
-----------------------------
The Batch files are still needed even when you are shelling directly to
the external protocol driver. I decided to do it this way so you could
change any parameter easily with any text editor. If you are using the
shell method, the RPC automatically rewrites the batch file into a string
that it uses to shell to the protocol driver. You can put these batch
files in any subdirectory, (mine is c:\ext) and if you don't add the '.BAT'
to the end of its name, RPC will do it for you. More on the batch files
below.
Method to use when calling this protocol
----------------------------------------
You have two options here, D means to shell directly to the protocol
driver. E means to Exit RBBS-PC and invoke the driver through a batch
file.
Success Check Method
--------------------
You also have two options here. DSZ, and anything else. This is because
DSZ outputs its log file in a different method than does QMXFER (or related
programs) If you are using DSZ (which seems to be best for almost all
protocols, at least the ones it supports) choose this method.. Because
DSZ -appends- to its log each time, the XFER-x.DEF must be deleted after each
transfer. The Other method of checking for success is the one mentioned
in the RBBS-PC docs, and the one currently implemented in RBBS-PC.
Mode
----
There are several modes that are going to be a part of RPC.
1 -- Reliable mode needed for this protocol
2 -- Don't print number of blocks in the file
3 -- Batch Transfer allowed (not implemented as of yet)
4 -- Same as Mode 2 plus, allow batch transfer (not implemented)
5 -- Mode 2 + Write out Fake Transfer report when using this protocol
(this is needed so RBBS doesn't crash upon return from a transfer)
6 -- Not used
7 -- Not used
8 -- 1k blocks
9 -- Mode 1 plus 1k blocks
Batch Files:
------------
First 4 samples of the batch files currently in use:
RZ.BAT
------
ECHO OFF
C:\ext\DSZ port %2 speed %1 rz %3
rbbs.bat
SZ.BAT
------
ECHO OFF
c:\ext\DSZ port %2 speed %1 sz %3
rbbs.bat
KERMITR.BAT
-----------
ECHO OFF
c:\ext\PCKERMIT -l COM%2 -b %1 -m 31 -p %4 -r %3 -c
cls
rbbs.bat
KERMITS.BAT
-----------
ECHO OFF
c:\ext\PCKERMIT -l COM%2 -b %1 -m 31 -p %4 -s %3 -c
cls
rbbs.bat
As you can see, all the batch files have a few things in common. First,
there MUST be a line before the actual transfer line.. In this case ECHO
OFF. Then comes the Transfer line. RPC looks at the line like this:
%1 -- baud rate (300,1200.. etc.)
%2 -- comm port (1 or 2)
%3 -- file name
%4 -- parity (E or N)
%5 -- node number for QMXFER program (not needed for DSZ)
After the actual transfer line you can have any command(s) you want.
If using the Exit RBBS-PC method, then RPC will execute the batch file
with those parameters. When using the shell Directly to the protocol
driver, RPC first loads the SECOND line of the batch file into memory,
then rewrites it with the necessary info.. So, the RZ.BAT would get parsed
into this:
C:\ext\DSZ port 1 speed 2400 rz d:\rbbs-pc\rbbs-src.arc
and then RPC would then SHELL that string.
You could rewrite the actual command line to read anything like:
C:\ext\DSZ port %2 speed %1 z pL1024 rz %3
which would then be:
C:\ext\DSZ port 1 speed 2400 z pL1024 rz d:\rbbs-pc\rbbs-src.arc
So, customization of the batch files is all that is needed to change
things around to your liking.
Some other ideas: I put Kermit as an Exit RBBS-PC type of protocol just
as an experiment. Practical uses of the Exit RBBS method are quite a
few in number... First, it will save you large amounts of memory over
the SHELL method. Second, for protocol drivers like... CLINK.EXE which
are usually invoked like this:
C>CLINK
You could make CLINKR.BAT use the Exit RBBS method, have your batch file
change directories to your upload directory, and then perform the transfer
that way the file ends up where it should, then get back to your RBBS
directory and the reinvoke your RBBS batch file. (check out the supplied
.BAT files for more info on how to use CLINK or MEGALINK)
Compiling info:
---------------
I compile RBBS-PC using QuickBASIC 3.0 using the following
commands (in my RBBSCOMP.BAT):
QB RBBS-PC /O;
IF NOT ERRORLEVEL 1 QB RBBSSUB1 /X/C:512/O;
IF NOT ERRORLEVEL 1 QB RBBSSUB2 /O;
IF NOT ERRORLEVEL 1 QB RBBSSUB3 /O;
LINK @LINKLST3.DAT
NOTE: This is different than the RBBS-PC docs say! As I have already
mentioned, RBBS-PC.BAS does NOT have an ON ERROR statement, nor any
RESUME linenumber statements, so it can be compiled without the /E
option thus reducing the size of the program, and opening up new vistas
in code space. This is the reason the NEW RPC Merge can add 10k of code
to RBBS-PC.BAS and still fit into it without any modifications.
Compiler Compatibility:
-----------------------
This merge was written to be compiled under QuickBASIC 1.0 or greater,
and does NOT contain END IF statements like the last version of the RPC
Merge.
Famous Last Words:
------------------
I hope I accomplished something here which everyone will like.
It sure has made my life easier.. and just the fact that I know I
won't have to recompile my program everytime something fails is a life
saver to me.
I hope to have batch transfer mod for the RPC soon. In my Original
14-1x and 15-1x DSZ Merge I explained how to implement a simple batch
transfer in the RBBS-PC code.. I hope to expand on this idea.
RPC Merge Release info:
-----------------------
12/25/87 (release 2 15-1C)
Rewrote the first two lines found at line 13390 in RPC-PC.MRG so QB3 would
compile without a hitch. Also added 4 more batch files for both the
Sealink, and Megalink protocols. I also want to thank those poeple who
reported their problems to me, so we could get this worked out.
12/28/87 (release 3 15-1C)
I clarified the docs so they are understood correctly. Also fixed a small
problem in line 13390 which would cause a file already open error and crash
the system (which just crept up after a month and a half of faithful
service)
01/02/88 (release 4 15-1C)
Fixed 'BAD FILE NUMBER' error.. RPC deleted the CALL OPENCOM(...) in
the ANSWERIT SUB in RBBSSUB1.BAS. Also fixed the LINK error message
caused by the missing LOGERRMSG subroutine.
04/13/88 (release 1 16-1A)
What me worry? Yes, I am releasing this on the 13th.. hope that date
doesn't have any significance! I BLED Merged it.. Compiled it.. Ran it..
'Looked' like it was working fine.. but you all know how that goes..
BUGS you say? Let me know right away!
If you have any further Ideas, Suggestions, Bug fixes, or whatever, give
me a ring at:
John Morris
The Reno RBBS
Home of the RPC Merge, GMon, and Tradewars!
702-746-1364 DATA (J)oin the RBBS-PC conference)
702-746-1365 DATA
702-746-1358 VOICE (varied hours on the voice line)